3장. 바이브 코딩의 가치

출처 — 진 킴·스티브 예기, 『바이브 코딩: 프로덕션의 원칙』(제이펍, 2026), 3장 (pp. 87~101). 원문 PDF vibe_coding_final_v11_260913.pdf (2026-09-13 판)

속도는 바이브 코딩이 주는 가장 눈에 띄는 이점이지만, 저자들이 말하는 진짜 가치는 그 속도가 배가시키는 나머지 네 가지 — 야심·자율성·재미·옵셔널리티 — 에 있다. 이 장은 이 다섯 가지를 FAAFO라는 이름으로 묶어 하나씩 깊이 들여다본다.

학습 목표

이 장을 끝내면 다음을 할 수 있다.

• FAAFO를 구성하는 다섯 가지 가치(빠름·야심·자율성·재미·옵셔널리티)를 각각 설명한다.
• 속도가 나머지 네 가치를 배가시키는 메커니즘을 사례를 들어 설명한다.
• 조율 비용·독심술 비용이라는 개념으로 자율성의 가치가 왜 커지는지 구분해 설명한다.
• 원웨이 도어와 옵셔널리티 개념을 실제 의사결정 상황에 적용해 어느 쪽이 유리한지 판단한다.
• AI를 코드 생성기로 쓰는 경우와 컨시어지(설계 파트너·탐정)로 쓰는 경우의 차이를 비교한다.

전체 흐름도

[ FAAFO — 바이브 코딩이 만드는 다섯 가지 가치 ]
   "속도가 전부"라 생각하면 핵심을 놓친다 — 'B(better)'는 빠져 있다
        │
        ▼
   빠름(Fast) ── 속도 자체가 아니라 "나머지 넷을 배가시키는 힘"
        │           예: 영상 클립 추출 도구 47분 완성
        ▼
   야심(Ambitious) ── 시도조차 못했던 일이 백로그에 오른다
        │           예: 5개월 프로젝트 → 5주/5일, 캣 우의 "10분 만에 버그 수정"
        ▼
   자율성(Autonomous) ── 조율 비용·독심술 비용이 사라진다 → 드리프트(the Drift)
        │           예: 리샤브의 반나절 프로젝트, 피자 두 판 팀, 브룩스 법칙
        ▼
   재미(Fun) ── 지루한 작업이 사라지고 몰입(도파민 보상)이 온다
        │           예: RCT 84% 긍정 응답, 아디다스 개발자 91%
        ▼
   옵셔널리티(Optionality) ── 원웨이 도어를 되돌릴 수 있는 실험으로 바꾼다
        │           예: 토요타의 모듈형 생산, 아마존의 마이크로서비스 전환
        ▼
[ 최고의 컨시어지, AI ] ── 코드 생성기를 넘어 탐정·설계 파트너 역할
        │
        ▼
4장 「바이브 코딩의 어두움」 — 같은 FAAFO의 이면(위험과 실패 양상)

0. 용어 사전

참고 — 위쪽 1개는 이 장을 읽기 전에 알아야 하는 선행 용어다. 나머지는 이 장이 처음 깊이 다루는 개념이라 선행으로 표시하지 않았다. 낯설면 1장을 먼저 보라.

1. FAAFO — 왜 속도만이 전부가 아닌가

바이브 코딩이 코딩 속도를 높인다는 사실은 자명하고, 사람들이 가장 열광하는 지점도 바로 이것이다. 그러나 속도가 전부라고 생각하면 핵심을 놓친다. 저자들은 바이브 코딩이 다섯 가지 차원에서 가치를 만들어낸다고 보고, 이를 FAAFO — 빠름(Fast)·야심(Ambitious)·자율성(Autonomous)·재미(Fun)·옵셔널리티(Optionality) — 라 이름 붙였다.

FAAFO를 새로 얻은 초능력이라 생각해보면, 더 빨리 코드를 작성하고, 예전이라면 불가능하다고 여겼을 프로젝트에 과감히 도전하며, 과거에는 팀이 필요했던 일을 혼자 해내고, AI가 즐거움을 되돌려주는 동시에 여러 해결책을 동시에 탐색할 수 있게 된다.

FAAFO에는 의도적으로 'B(better)'가 빠져 있다. 바이브 코딩이 코드를 자동으로 더 좋게 만들어주지는 않는다 — 더 나은 코드를 구현하는 책임은 여전히 개발자의 몫이다. 다만 이 책이 제시하는 기법을 따른다면, 다른 FAAFO의 이점과 더불어 더 나은 코드와 더 나은 개발자로 거듭날 최고의 기회를 얻을 수 있다.

2. 빠름(Fast) — 속도가 나머지 넷을 배가시키는 힘

속도는 바이브 코딩이 주는 가장 표면적인 가치다. AI의 코드 생성 속도 자체는 놀랍지만, 과거에도 다양한 IT 기술 발전이 여러 차례 속도 향상을 가져다주었다는 점에서 속도 그 자체가 가치를 만드는 것은 아니다. 속도가 진짜 중요한 이유는 FAAFO의 나머지 네 가치를 배가시키는 힘이기 때문이다.

저자인 스티브와 진이 함께 만든 영상 클립 추출 도구가 그 예다. 팟캐스트나 긴 영상에서 클립을 자동으로 뽑아내는 이 도구를, 두 사람은 에이전트형 AI 도구 없이 단순한 채팅형 AI만으로 47분 만에 작동하는 첫 버전으로 완성했다. 진은 "이걸 손으로 코딩했다면 이삼일은 걸렸을 것"이라 평가했다.

이 공동 작업에서 얻은 핵심 교훈은 "타이핑은 줄이고, AI에 더 의지하라"는 것이다. 그러나 동시에 AI가 오히려 속도를 떨어뜨리는 경우도 있다는 것을 깨달았다 — 진은 ffmpeg로 영상에 자막·이미지를 정확히 배치하려다 몇 시간을 삽질했고, 스티브는 그레이들 빌드 스크립트의 인자 파싱에서 AI가 제시한 모든 방식이 틀려 오후를 통째로 날렸다. 그래서 바이브 코더에게는 AI가 엉뚱한 방향으로 달려갈 때 함정을 알아차리고 방향을 틀거나 포기할 시점을 판단하는 감각이 필요하다.

참고 — 개발자는 일반적으로 전체 시간의 약 25%만 코드 작성에 쓰고, 그 두 배에 달하는 시간을 코드를 읽는 데 쓴다는 지적도 있다. 코드 작성 외의 활동에서 AI를 활용하는 방법은 책 후반부에서 다룬다.

그럼에도 저자들은 바이브 코딩을 사랑한다고 말한다. 인터넷이나 LLM을 쓸 수 없는 환경에서는 아예 코딩하지 않는 개발자도 있을 정도다 — 손으로 코드를 작성하는 일은, 차를 쓸 수 없는 상황에서 70마일(약 113km)이나 되는 사막 도로를 몇 시간이나 기다렸다 지나가는 차를 얻어 타는 대신 굳이 땡볕을 걸어가는 것과 같다는 비유다. 저자들은 손 코딩을 2010년대의 유물로 본다.

3. 야심(Ambitious) — 시도조차 못했던 일이 백로그에 오르다

영상 클립 추출 도구는 바이브 코딩이 없었다면 며칠이 걸려 시도할 엄두조차 내지 못했을 작업이었다. 프로젝트가 시작조차 되지 못하는 이유는 다양하다 — 예상 성과가 노력에 비해 작거나, 난도 대비 보상이 부족하거나, 더 높은 수익을 낼 다른 기회가 있기 때문이다. 그러나 바이브 코딩 덕분에 진은 원래라면 영원히 미뤘을 작업을 완성했고, 5개월짜리 프로젝트가 5주 혹은 5일 만에 끝나는 일도 벌어진다.

작은 일감들도 이슈로 등록하기보다 바로 처리하는 편이 쉬워졌다. 문서화·테스트 코드 작성·자잘한 UI 개선·소규모 리팩터링처럼 늘 우선순위에서 밀려났던 일들이 몇 초, 몇 분 안에 끝나면서 깨진 유리창 이론처럼 쌓여가던 기술 부채가 사라진다. 앤트로픽 클로드 코드 팀의 프로젝트 매니저 캣 우는 이렇게 말했다. "고객 지원 팀에서 '앱에 이런 버그가 있어요'라고 이슈를 생성하면, 10분 후에 엔지니어 중 한 명이 '클로드 코드가 버그를 고쳤습니다'라고 답하는 수준까지 왔습니다. 클로드 코드가 없었다면 아마 그 버그는 백로그에 묻혀 있었을 거예요." 문제를 문서화하거나 우선순위를 정하는 것보다 바로 해결하는 편이 빠른 경우는 늘 있었지만, 이제는 AI 덕분에 그런 경우의 종류 자체가 훨씬 많아졌다.

4. 자율성(Autonomous) — 조율 비용과 독심술 비용을 없애다

2024년 6월, 소스그래프의 AI 총괄이었던 리샤브 메흐로트라는 바이브 코딩으로 아이디어 구상부터 배포까지 반나절 만에 만든 멀티클래스 예측 모델 데모를 스티브에게 보여주었다. 리샤브는 "불과 1년 전만 해도 이 프로젝트는 천재 인턴이라도 최소 6주는 걸렸을 것"이라 말했지만, 실제로 걸린 시간은 불과 몇 시간이었다. 인턴을 고용할 예산이 없어 직접 해본 것이 오히려 "혼자서도 충분하다"는 사실을 깨닫는 계기가 됐다.

이 사례는 바이브 코딩이 만드는 세 번째 가치인 자율성을 보여준다. 공동 작업에는 커뮤니케이션·협업·우선순위 충돌·결과물 병합 같은 이유로 조율 비용이 필연적으로 발생하고, 참여 인원이 늘수록 정작 문제 해결에 쓰는 시간은 줄어드는 역설이 생긴다. 스티브가 아마존에서 경험한 피자 두 판 팀(6~10명 규모)은 다른 팀·윗선의 승인 없이 문제에 완전한 소유권을 갖고 자율적으로 해결책을 배포할 수 있었다.

참고 — 브룩스 법칙 지연된 프로젝트에 인력을 추가하면 늘어난 통신 오버헤드 때문에 오히려 더 늦어진다는 법칙이다. 팀 규모가 커질수록 통신 경로 수는 기하급수로 늘어나 3명일 때 3개였던 경로가 10명일 때는 45개가 된다.

조율 비용 외에도 협업에는 피할 수 없는 독심술 비용이 있다 — 아무리 뛰어난 동료라도 내 머릿속을 100% 알지 못한다. 하버드대 매트 빈 박사가 15년간 연구한 수술용 로봇 사례가 이를 보여준다. 로봇 도입 전에는 시니어 외과의사 곁에서 주니어 의사가 보조하는 도제 시스템이 자연스럽게 만들어졌지만, 로봇이 도입되어 혼자 수술이 가능해지자 시니어 의사 대부분이 교육 때문이 아니라 조율에 드는 비용이 생각보다 컸기 때문에 혼자 하는 쪽을 택했다. 보조 의사라는 물리적 필요가 사라지자 협업의 진짜 비용이 드러난 것이다.

경제학자 대니얼 록 박사는 조율과 독심술 비용이 사라진 상태를 영화 〈퍼시픽 림〉에서 따온 드리프트라 불렀다 — 두 조종사가 정신적으로 완전히 동기화되어 거대 로봇을 조종하는 상태다. 드리프트 상태에서는 제품 담당자가 상세한 요구 사항 문서 없이도 AI로 코드베이스를 직접 다루고, 개발자는 전문가 도움 없이 데이터베이스 스키마를 고도화할 수 있다. 어도비 최고 제품 책임자 스콧 벨스키는 이를 스택 붕괴라 표현했다 — 한 사람이 개발 프로세스의 더 많은 부분에 관여할 수 있게 되는 이점이다.

5. 재미(Fun) — 지루함을 걷어내고 몰입을 되찾다

전통적인 프로그래밍에는 문법·타입 에러 수정, 낯선 패키지 매니저 다루기, 보일러플레이트 코드 작성, 문서 찾기처럼 개발자 다수가 좋아하지 않는 지루한 작업이 많다. 바이브 코딩은 이런 과정을 없애고 초점을 "무언가를 만드는 일"로 옮긴다.

생성형 AI 코딩 도구를 쓰는 개발자 대상 무작위 대조 실험에서 84%가 AI 도구 사용 후 업무 방식에 긍정적 변화가 있었다고 답했다 — 코딩에 더 흥미를 느끼고, 스트레스는 줄었으며, 문서 작성조차 즐길 정도였다. 아디다스에서는 700명의 개발자가 매일 깃허브 코파일럿을 쓰고 있고, 그중 91%가 코파일럿 없이는 일하고 싶지 않다고 답했다. 아디다스 디지털 기술 부문 부사장 페르난도 코르나고는 바이브 코딩 덕분에 개발자들이 생산성을 높이는 시간인 '행복한 시간'에 50% 더 많은 시간을 쓰고 있다고 설명했다 — 불안정한 테스트나 회의로 씨름해야 하는 '짜증 나는 시간'과는 정반대되는 개념이다.

AI 에이전트와 함께하는 바이브 코딩은 키보드를 슬롯머신 레버처럼 당기기만 해도 코드 덩어리·테스트 코드·리팩터링 결과물 같은 작은 당첨금이 즉시 나온다. 이 당첨금은 한 번 더 레버를 당기게 만드는 도파민 자극을 일으켜, 저자들도 몰입한 나머지 시간이 사라지는 경험을 여러 번 했다고 말한다.

6. 옵셔널리티(Optionality) — 결정을 미룰 수 있는 권리의 가치

FAAFO의 다섯 번째 가치는 결정을 내리기 전에 여러 선택지를 탐색할 수 있는 능력이며, 저자들은 이를 가장 심오한 가치로 꼽는다. 과거에는 기술 스택 선택 같은 설계 결정이 정보가 제한된 상태에서 내려야 하는, 아마존이 말하는 원웨이 도어(한 번 통과하면 되돌리기 어렵거나 매우 비싼 결정)였다. 바이브 코딩은 여러 경로를 병렬로 탐색하는 비용을 낮춰 이 제약을 깬다 — 개발자는 강아지와 45분 산책하며 AI와 음성으로 대화해 복잡한 라이브러리·프레임워크 생태계 속 결정을 평가받을 수 있고, 오후 반나절 만에 RESTful·GraphQL·gRPC 세 가지 아키텍처로 프로토타입 API를 각각 구현해 비교할 수 있다.

옵셔널리티(옵션이라는 개념)는 1970년대 금융업에서 정립됐다 — 옵션이란 미래에 결정을 내릴 '권리'이지 '의무'는 아니다. 옵션의 가치는 불확실성과 위험 대비 보상 비율이 높을수록 커지고, 불확실성이 없을 때는 최선을 바로 고르면 되므로 옵션 자체가 필요 없어진다. 지금처럼 AI의 불확실성이 높은 시기에는 옵션의 가치가 극도로 커지므로, 선택지를 빼앗는 장기 결정을 피하는 편이 유리하다.

토요타는 이미 수십 년 전 제조업에서 옵션 가치의 중요성을 발견했다. 미국 제조업체들이 표준화·고정 방식에 집중하는 동안, 토요타는 모듈형 생산 라인과 빈번한 실험, 하루 4,000건 이상 현장 작업자가 즉시 생산 라인을 멈추기도 하는 빠른 피드백 사이클로 유연성과 적응성을 높였다. 그 결과 서로 다른 연식·사양의 차량을 같은 라인에서 병행 생산하고 하루에도 수십 번 라인을 바꿀 수 있게 됐다.

참고 — 로버트 머턴 박사는 피셔 블랙 박사·마이런 숄스 박사와 함께 옵션 가격 결정 연구를 했고, 그 공로로 머턴과 숄스 박사가 1997년 노벨 경제학상을 받았다. 블랙 박사는 1995년 별세해 노벨상 규정상(사후 수여 없음) 수상 대상에서 제외됐다 — 원문은 블랙 박사도 함께 수상한 것으로 적었으나, 노벨상 공식 발표는 그해 수상자를 머턴·숄스 두 사람으로 명시하고 있다(노벨상 공식 발표).

옵셔널리티는 아마존이 2000년대 초반 기존 아키텍처를 마이크로서비스 아키텍처로 전환했을 때(스티브도 그 과정의 일원이었다) 새 비즈니스 모델을 재빠르게 실험할 수 있었던 이유이기도 하다. 이 전환은 AWS를 1,000억 달러 규모 비즈니스로 키우는 밑거름이 됐고, 경쟁사들은 자사 아키텍처가 발목을 잡아 쉽게 따라잡지 못했다. AI는 변화 비용을 낮춰 선택지를 탐색하는 시간·비용을 줄여주지만, 이를 가능하게 하려면 모듈형 아키텍처를 갖추는 것이 전제 조건이다.

7. 최고의 컨시어지, AI

AI 어시스턴트는 단순한 코드 생성기 이상이다. 세계적인 레스토랑의 헤드 셰프가 요리와 무관한 온갖 문제에 부딪히듯, 개발자도 코딩 외의 문제를 자주 만난다 — 이때 AI는 소믈리에이자 탐정, 회계사, 변호사 역할까지 해내는 24시간 대기 컨시어지가 된다.

자체 작성 — Claude Sonnet 5 · spec 8.4 · 최초 2026-09-14 · 수정 2026-09-14 · 검증: 아래 절차를 그대로 따라 손으로 재현, 서술한 흐름과 일치 목적 — 원문이 서술한 "AI가 깃 히스토리를 탐정처럼 뒤지는" 상황을 판단 시나리오로 정리해 확인. 원서 내용이 아니다.

상황 — 커밋 200과 커밋 100 사이 어딘가에서 테스트 파일이 사라졌다는 것만 알고, 정확히 몇 번째 커밋인지는 모른다.

전통적 접근 — 개발자가 git log와 git diff를 커밋 하나씩 열어 파일 목록을 눈으로 비교한다. 100개 커밋을 다 훑으려면 수동 이분 탐색을 하더라도 여러 차례 명령을 반복해야 하고, 사라진 파일을 복원하려면 그 커밋의 변경 내용을 별도로 파악해야 한다.

AI 활용 접근 — "커밋 200과 커밋 100 사이 어딘가에서 테스트 파일이 사라졌어"라고 자연어로 요청하면, AI가 깃 히스토리를 훑어 "43개의 커밋 전으로 거슬러 올라가면 있네요"라고 답한다. 이어서 "테스트 파일들을 추출했고, 그것들을 참조하는 빌드 설정도 함께 복원했습니다"처럼 원인 파악과 복원을 한 번에 처리한다.

왜 — 개발자가 직접 파고들면 몇 시간이 걸릴 탐색을, AI에게 자연어로 맡기면 몇 초~몇 분으로 줄일 수 있다. 이는 FAAFO의 빠름(속도)과 자율성(다른 사람의 도움 없이 혼자 해결) 두 가치를 동시에 실현하는 사례다.

저자들은 AI에게 열 번째 중첩보다 깊은 곳에 묻힌 값을 찾아 달라고 요청한 적도 있다. AI는 몇 초 안에 원하는 정보가 ['server']['cluster']['node_13']['overrides']['sandbox']['temporary'] 아래에 있다고 답했다.^* AI는 설계 파트너로서 시간에 구애받지 않고, 아이디어를 검증하거나 며칠째 원인을 못 찾은 성능 문제를 디버깅하는 데도 도움을 준다. 다만 저자들은 이런 실수가 AI 자체보다는 AI를 쓰는 인간 때문에 생기는 경우가 많다고 짚으며, 작은 작업만 처리하고 진행 상황을 주의 깊게 추적하는 규칙 있는 접근이 전제될 때 AI 컨시어지가 가장 유용하다고 결론짓는다.

_{* 원문 인쇄본은 이 경로 표기의 대괄호·따옴표 일부가 추출 과정에서 깨져 있었다(예: ['node_13]처럼 닫는 대괄호 누락). 의도한 경로가 명확해 여기서는 정상적인 대괄호 표기로 복원했다.}

핵심 개념 정리

실무 체크리스트

• [ ] 이 작업에서 속도가 진짜 목표인지, 아니면 속도가 배가시킬 다른 가치(야심·자율성·재미·옵셔널리티)가 진짜 목표인지 구분했는가?
• [ ] AI가 제시한 접근이 틀렸을 때 방향을 틀거나 포기할 기준을 미리 정해 두었는가?
• [ ] 원래라면 백로그에서 영원히 밀렸을 작은 작업을, 바로 처리할 수 있는지 살펴보았는가?
• [ ] 이 결정이 원웨이 도어인지 되돌릴 수 있는 결정인지 먼저 분류했는가?
• [ ] 되돌릴 수 없는 결정이라면, 여러 옵션을 병렬로 값싸게 탐색할 방법을 먼저 찾아보았는가?
• [ ] 팀 협업에서 조율 비용이 실제 문제 해결 시간을 얼마나 잡아먹고 있는지 가늠해보았는가?
• [ ] AI를 코드 생성기로만 쓰고 있진 않은지, 탐정·설계 파트너로도 활용할 여지가 있는지 점검했는가?
• [ ] 새 아키텍처·기술 스택을 고를 때, 나중에 바꿀 수 있도록 모듈형으로 설계했는가?

연습문제

1. 개념. FAAFO에 'B(better)'가 빠져 있는 이유를 설명하고, 이것이 바이브 코딩을 쓰는 개발자의 책임에 대해 무엇을 말해주는지 논하라.
2. 적용. 당신의 팀이 5명에서 15명으로 늘어나려 한다. 브룩스 법칙과 피자 두 판 팀 개념을 근거로, 이 확장이 조율 비용에 어떤 영향을 줄지, 그리고 어떻게 팀을 구성해야 자율성을 지킬 수 있을지 제안하라.
3. 비교. 원웨이 도어와 옵셔널리티가 만드는 되돌릴 수 있는 결정의 차이를 설명하고, 신규 데이터베이스 선택처럼 되돌리기 어려운 결정에서 바이브 코딩이 어떤 식으로 위험을 낮출 수 있는지 논하라.
4. 분석. 아디다스 사례(700명, 91%)와 무작위 대조 실험(84%)이 각각 FAAFO의 어느 가치를 뒷받침하는 근거인지 밝히고, 두 수치가 왜 다른 종류의 증거인지(사례 연구 vs 실험) 설명하라.
5. 설계. 당신 팀이 새 기능을 만들 때 아키텍처를 확정하기 전 단계에서, 이 장의 "오후 반나절 만에 세 가지 아키텍처를 구현해 비교" 사례를 참고해 어떤 실험 절차를 설계할지 제안하라.

부록 A. 핵심 비교표

원웨이 도어 vs 옵셔널리티가 만드는 되돌릴 수 있는 실험

조율 비용(다인 협업) vs 드리프트(AI와의 완전 동기화)

토요타의 모듈형 유연 생산 vs 미국 제조업의 표준화 고정 생산

부록 B. 추천 참고 자료

외부 자료 (Tier 1 공식, 생존 확인 2026-09-14)

• AWS 공식 — 피자 두 판 팀 — §4의 조율 비용·자율적 팀 구성 개념을 아마존이 직접 설명한 자료. Amazon's Two Pizza Teams — AWS Executive Insights
• 노벨상 공식 발표 — 1997년 경제학상 — §6에서 다룬 옵션 가격 결정 연구의 실제 수상자와, 원문이 놓친 피셔 블랙의 수상 제외 사유를 확인할 때. The Prize in Economic Sciences 1997 — NobelPrize.org
• GitHub Copilot 공식 페이지 — §5의 아디다스 사례(700명, 91%)가 쓴 도구의 현재 기능·요금을 확인할 때. GitHub Copilot
• Claude Code 공식 문서 — §3의 캣 우 사례·§7의 AI 컨시어지 활용이 실제로 어떤 도구로 이뤄지는지 살펴볼 때. Claude Code — Overview

본 책 연계 챕터

부록 C. 연습문제 풀이

1. (FAAFO에 'B'가 없는 이유) FAAFO는 바이브 코딩이 만들어내는 다섯 가치(빠름·야심·자율성·재미·옵셔널리티)의 머리글자이며, 'B(better)'는 의도적으로 빠져 있다. 이는 AI가 코드를 자동으로 더 좋게 만들어주지는 않는다는 뜻이며, 더 나은 코드를 구현하는 책임은 여전히 개발자에게 있다는 것을 말해준다. 즉 FAAFO는 바이브 코딩이 주는 기회를 나열할 뿐, 그 기회를 좋은 결과로 바꾸는 일은 개발자의 판단과 실천에 달려 있다.

2. (팀 확장과 조율 비용) 브룩스 법칙에 따르면 통신 경로 수는 인원의 제곱에 비례해 늘어나므로(5명 10개 경로 → 15명 105개 경로), 팀을 단순히 3배로 키우면 조율 비용은 그보다 훨씬 가파르게 증가한다. 피자 두 판 팀 개념을 적용하면, 15명을 한 팀으로 묶기보다 6~10명 규모의 독립적인 소팀 여러 개로 나누고 각 팀에 완전한 소유권을 주는 편이 자율성을 지키면서 확장하는 방법이다. 각 소팀이 다른 팀·윗선의 승인 없이 자기 영역을 책임지면, 인원이 늘어도 문제 해결에 쓰는 시간이 줄어드는 역설을 피할 수 있다.

3. (원웨이 도어 vs 옵셔널리티) 원웨이 도어는 한 번 통과하면 되돌리기 어렵거나 매우 비싼 결정이고, 옵셔널리티가 만드는 실험은 결정을 미루거나 여러 선택지를 값싸게 병렬로 시도해보는 것이다. 신규 데이터베이스 선택처럼 되돌리기 어려운 결정에서는, 바이브 코딩으로 후보 데이터베이스 여러 개에 대해 각각 프로토타입을 빠르게 구현해 실제 데이터로 성능·운영 부담을 비교한 뒤 결정할 수 있다. 이렇게 하면 정보가 제한된 상태에서 선불로 결정하던 과거 방식 대신, 구현 결과를 보고 판단하는 방식으로 위험을 낮춘다.

4. (아디다스 사례 vs 무작위 대조 실험) 아디다스 사례(700명, 91%)는 재미(Fun) 가치를 실제 조직에서 관찰된 사례 연구로 뒷받침하고, 무작위 대조 실험(84%)은 재미 가치를 통제된 실험 설계로 뒷받침한다. 두 수치는 성격이 다른 증거다 — 사례 연구는 특정 회사·도구(깃허브 코파일럿)라는 맥락 안에서 실제 사용자의 응답을 보여주는 반면, 무작위 대조 실험은 비교군을 두어 AI 도구 사용과 긍정적 변화 사이의 인과관계를 더 엄격하게 뒷받침한다. 두 증거를 함께 보면 특정 사례의 결과가 우연이 아니라 더 넓은 패턴의 일부임을 보여준다.

5. (아키텍처 실험 절차 설계) 이 장의 사례처럼, 후보 아키텍처(예: RESTful·GraphQL·gRPC) 각각에 대해 핵심 엔드포인트 하나를 프로토타입 수준으로 구현하는 작업을 병렬로 진행할 수 있다. 직렬화·에러 처리·클라이언트 통합까지 포함한 최소 기능을 짧은 시간 안에 완성해, 세 방식을 직접 손으로 비교하며 팀의 실제 요구 사항(성능·유지보수성·클라이언트 호환성)에 어느 쪽이 맞는지 판단한다. 이렇게 짧은 병렬 실험을 거치면, 정보가 부족한 상태에서 아키텍처를 원웨이 도어로 확정하는 대신 실제 구현 결과를 보고 결정할 수 있다.